SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Defensive programming</title>

</head>

Defensive programming

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}@media print{body.ns-0 .mw-parser-output .ambox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style>

Defensive programming is a form of <a href="Defensive_design" title="Defensive design">defensive design</a> intended to develop programs that are capable of detecting potential security abnormalities and make predetermined responses.<a href="#cite_note-1">[1]</a> It ensures the continuing function of a piece of <a href="Software" title="Software">software</a> under unforeseen circumstances. Defensive programming practices are often used where <a href="High_availability" title="High availability">high availability</a>, <a href="Safety" title="Safety">safety</a>, or <a href="Computer_security" title="Computer security">security</a> is needed.

Defensive programming is an approach to improve software and <a href="Source_code" title="Source code">source code</a>, in terms of:

<ul><li>General quality – reducing the number of <a href="Software_bug" title="Software bug">software bugs</a> and problems.</li>

<li>Making the source code comprehensible – the source code should be readable and understandable so it is approved in a <a href="Code_audit" title="Code audit">code audit</a>.</li>

<li>Making the software behave in a predictable manner despite unexpected inputs or user actions.</li></ul>

Overly defensive programming, however, may safeguard against errors that will never be encountered, thus incurring run-time and maintenance costs.

<div class="mw-heading mw-heading2"><h2 id="Secure_programming">Secure programming</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Secure_coding" title="Secure coding">Secure coding</a></div>

Secure programming is the subset of defensive programming concerned with <a href="Computer_security" title="Computer security">computer security</a>. Security is the concern, not necessarily safety or availability (the <a href="Software" title="Software">software</a> may be allowed to fail in certain ways). As with all kinds of defensive programming, avoiding bugs is a primary objective; however, the motivation is not as much to reduce the likelihood of failure in normal operation (as if safety were the concern), but to reduce the <a href="Attack_surface" title="Attack surface">attack surface</a> – the programmer must assume that the software might be misused actively to reveal bugs, and that bugs could be exploited maliciously.

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>int risky_programming(char *input) {

// ...

strcpy(str, input); // Copy input.

// ...

}

</pre></div>

The function will result in undefined behavior when the input is over 1000 characters. Some programmers may not feel that this is a problem, supposing that no user will enter such a long input. This particular bug demonstrates a vulnerability which enables <a href="Buffer_overflow" title="Buffer overflow">buffer overflow</a> <a href="Exploit_(computer_security)" title="Exploit (computer security)">exploits</a>. Here is a solution to this example:

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>int secure_programming(char *input) {

char str[1000+1]; // One more for the null character.

// ...

// Copy input without exceeding the length of the destination.

strncpy(str, input, sizeof(str));

// If strlen(input) >= sizeof(str) then strncpy won't null terminate.

// We counter this by always setting the last character in the buffer to NUL,

// effectively cropping the string to the maximum length we can handle.

// One can also decide to explicitly abort the program if strlen(input) is

// too long.

str[sizeof(str) - 1] = '\0';

// ...

}

</pre></div>

<div class="mw-heading mw-heading2"><h2 id="Offensive_programming">Offensive programming</h2></div>

<div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Offensive_programming" title="Offensive programming">Offensive programming</a></div>

Offensive programming is a category of defensive programming, with the added emphasis that certain errors should not be <a href="Graceful_degradation" class="mw-redirect" title="Graceful degradation">handled defensively</a>. In this practice, only errors from outside the program's control are to be handled (such as user input); the software itself, as well as data from within the program's line of defense, are to be trusted in this <a href="Methodology" title="Methodology">methodology</a>.

<div class="mw-heading mw-heading3"><h3 id="Trusting_internal_data_validity">Trusting internal data validity</h3></div>

<dl><dt>Overly defensive programming</dt></dl>

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>const char* trafficlight_colorname(enum traffic_light_color c) {

switch (c) {

case TRAFFICLIGHT_RED: return "red";

case TRAFFICLIGHT_YELLOW: return "yellow";

case TRAFFICLIGHT_GREEN: return "green";

}

return "black"; // To be handled as a dead traffic light.

}

</pre></div>

<dl><dt>Offensive programming</dt></dl>

switch (c) {

}

assert(0); // Assert that this section is unreachable.

}

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="Trusting_software_components">Trusting software components</h3></div>

<dl><dt>Overly defensive programming</dt></dl>

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>if (is_legacy_compatible(user_config)) {

// Strategy: Don't trust that the new code behaves the same

old_code(user_config);

} else {

// Fallback: Don't trust that the new code handles the same cases

if (new_code(user_config) != OK) {

old_code(user_config);

}

}

</pre></div>

<dl><dt>Offensive programming</dt></dl>

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>// Expect that the new code has no new bugs

if (new_code(user_config) != OK) {

// Loudly report and abruptly terminate program to get proper attention

report_error("Something went very wrong");

exit(-1);

}

</pre></div>

<div class="mw-heading mw-heading2"><h2 id="Techniques">Techniques</h2></div>

Here are some defensive programming techniques:

<div class="mw-heading mw-heading3"><h3 id="Intelligent_source_code_reuse">Intelligent source code reuse</h3></div>

If existing code is tested and known to work, reusing it may reduce the chance of bugs being introduced.

However, reusing code is not always good practice. Reuse of existing code, especially when widely distributed, can allow for exploits to be created that target a wider audience than would otherwise be possible and brings with it all the security and vulnerabilities of the reused code.

When considering using existing source code, a quick review of the modules(sub-sections such as classes or functions) will help eliminate or make the developer aware of any potential vulnerabilities and ensure it is suitable to use in the project.

<div class="mw-heading mw-heading4"><h4 id="Legacy_problems">Legacy problems</h4></div>

Before reusing old source code, libraries, APIs, configurations and so forth, it must be considered if the old work is valid for reuse, or if it is likely to be prone to <a href="Legacy_system" title="Legacy system">legacy</a> problems.

Legacy problems are problems inherent when old designs are expected to work with today's requirements, especially when the old designs were not developed or tested with those requirements in mind.

Many software products have experienced problems with old legacy source code; for example:

<ul><li><a href="Legacy_code" class="mw-redirect" title="Legacy code">Legacy code</a> may not have been designed under a defensive programming initiative, and might therefore be of much lower quality than newly designed source code.</li>

<li>Legacy code may have been written and tested under conditions which no longer apply. The old quality assurance tests may have no validity any more.

<ul><li>Example 1: legacy code may have been designed for ASCII input but now the input is <a href="UTF-8" title="UTF-8">UTF-8</a>.</li>

<li>Example 2: legacy code may have been compiled and tested on 32-bit architectures, but when compiled on 64-bit architectures, new arithmetic problems may occur (e.g., invalid signedness tests, invalid type casts, etc.).</li>

<li>Example 3: legacy code may have been targeted for offline machines, but becomes vulnerable once network connectivity is added.</li></ul></li>

<li>Legacy code is not written with new problems in mind. For example, source code written in 1990 is likely to be prone to many <a href="Code_injection" title="Code injection">code injection</a> vulnerabilities, because most such problems were not widely understood at that time.</li></ul>

Notable examples of the legacy problem:

<ul><li><a href="BIND" title="BIND">BIND 9</a>, presented by Paul Vixie and David Conrad as "BINDv9 is a <a href="Rewrite_(programming)" title="Rewrite (programming)">complete rewrite</a>", "Security was a key consideration in design",<a href="#cite_note-2">[2]</a> naming security, robustness, scalability and new protocols as key concerns for rewriting old legacy code.</li>

<li><a href="Microsoft_Windows" title="Microsoft Windows">Microsoft Windows</a> suffered from "the" <a href="Windows_Metafile_vulnerability" title="Windows Metafile vulnerability">Windows Metafile vulnerability</a> and other exploits related to the WMF format. Microsoft Security Response Center describes the WMF-features as "Around 1990, WMF support was added... This was a different time in the security landscape... were all completely trusted",<a href="#cite_note-3">[3]</a> not being developed under the security initiatives at Microsoft.</li>

<li><a href="Oracle_Corporation" title="Oracle Corporation">Oracle</a> is combating legacy problems, such as old source code written without addressing concerns of <a href="SQL_injection" title="SQL injection">SQL injection</a> and <a href="Privilege_escalation" title="Privilege escalation">privilege escalation</a>, resulting in many security vulnerabilities which have taken time to fix and also generated incomplete fixes. This has given rise to heavy criticism from security experts such as <a href="David_Litchfield" title="David Litchfield">David Litchfield</a>, Alexander Kornbrust, Cesar Cerrudo.<a href="#cite_note-4">[4]</a><a href="#cite_note-5">[5]</a><a href="#cite_note-6">[6]</a> An additional criticism is that default installations (largely a legacy from old versions) are not aligned with their own security recommendations, such as <a href="Oracle_Database" title="Oracle Database">Oracle Database</a> Security Checklist, which is hard to amend as many applications require the less secure legacy settings to function correctly.</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Canonicalization">Canonicalization</h3></div>

Malicious users are likely to invent new kinds of representations of incorrect data. For example, if a program attempts to reject accessing the file "/etc/<a href="Passwd_(file)" class="mw-redirect" title="Passwd (file)">passwd</a>", a cracker might pass another variant of this file name, like "/etc/./passwd". <a href="Canonicalization" title="Canonicalization">Canonicalization</a> libraries can be employed to avoid bugs due to non-<a href="Canonical_form" title="Canonical form">canonical</a> input.

<div class="mw-heading mw-heading3"><h3 id="Low_tolerance_against_"potential"_bugs">Low tolerance against "potential" bugs</h3></div>

Assume that code constructs that appear to be problem prone (similar to known vulnerabilities, etc.) are bugs and potential security flaws. The basic rule of thumb is: "I'm not aware of all types of <a href="Security_exploit" class="mw-redirect" title="Security exploit">security exploits</a>. I must protect against those I do know of and then I must be proactive!".

<div class="mw-heading mw-heading3"><h3 id="Other_ways_of_securing_code">Other ways of securing code</h3></div>

<ul><li>One of the most common problems is unchecked use of constant-size or pre-allocated structures for dynamic-size data such as inputs to the program (the <a href="Buffer_overflow" title="Buffer overflow">buffer overflow</a> problem). This is especially common for <a href="String_(computer_programming)" class="mw-redirect" title="String (computer programming)">string</a> data in <a href="C_(programming_language)" title="C (programming language)">C</a>. C library functions like <code>gets</code> should never be used since the maximum size of the input buffer is not passed as an argument. C library functions like <code>scanf</code> can be used safely, but require the programmer to take care with the selection of safe format strings, by sanitizing it before using it.</li>

<li>Encrypt/authenticate all important data transmitted over networks. Do not attempt to implement your own encryption scheme, use a <a href="Cryptography_standards" title="Cryptography standards">proven one</a> instead. Message checking with a hash or similar technology will also help secure data sent over a network.</li></ul>

<div class="mw-heading mw-heading4"><h4 id="The_three_rules_of_data_security">The three rules of data security</h4></div>

<ul><li>All <a href="Data" title="Data">data</a> is important until proven otherwise.</li>

<li>All data is tainted until proven otherwise.</li>

<li>All code is insecure until proven otherwise.

<ul><li>You cannot prove the security of any code in <a href="Userland_(computing)" class="mw-redirect" title="Userland (computing)">userland</a>, or, more commonly known as: "never trust the client".</li></ul></li></ul>

These three rules about data security describe how to handle any data, internally or externally sourced:

All data is important until proven otherwise - means that all data must be verified as garbage before being destroyed.

All data is tainted until proven otherwise - means that all data must be handled in a way that does not expose the rest of the runtime environment without verifying integrity.

All code is insecure until proven otherwise - while a slight misnomer, does a good job reminding us to never assume our code is secure as bugs or <a href="Undefined_behavior" title="Undefined behavior">undefined behavior</a> may expose the project or system to attacks such as common <a href="SQL_injection" title="SQL injection">SQL injection</a> attacks.

<div class="mw-heading mw-heading4"><h4 id="More_Information">More Information</h4></div>

<ul><li>If data is to be checked for correctness, verify that it is correct, not that it is incorrect.</li>

<li><a href="Design_by_contract" title="Design by contract">Design by contract</a></li>

<li><a href="Assertion_(computing)" class="mw-redirect" title="Assertion (computing)">Assertions</a> (also called assertive programming)</li>

<li>Prefer <a href="Exception_handling" title="Exception handling">exceptions</a> to return codes

<ul><li>Generally speaking, it is preferable to throw exception messages that enforce part of your <a href="Application_programming_interface" class="mw-redirect" title="Application programming interface">API</a> <a href="Design_by_contract" title="Design by contract">contract</a> and guide the developer instead of returning error code values that do not point to where the exception occurred or what the program stack looked liked, Better logging and exception handling will increase robustness and security of your software, while minimizing developer stress.</li></ul></li></ul>

<ul><li><a href="Computer_security" title="Computer security">Computer security</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFBoulanger2016" class="citation cs2">Boulanger, Jean-Louis (2016-01-01), Boulanger, Jean-Louis (ed.), <a rel="nofollow" class="external text" href="https://www.sciencedirect.com/science/article/pii/B9781785481178500064">"6 - Technique to Manage Software Safety"</a>, Certifiable Software Applications 1, Elsevier, pp. 125–156, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1-78548-117-8</bdi>, retrieved 2022-09-02</cite>

</li>

<li id="cite_note-2"><a href="#cite_ref-2">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://impressive.net/archives/fogo/20001005080818.O15286@impressive.net">"fogo archive: Paul Vixie and David Conrad on BINDv9 and Internet Security by Gerald Oskoboiny"</a>. impressive.net. Retrieved 2018-10-27.</cite>

</li>

<li id="cite_note-3"><a href="#cite_ref-3">^</a> <cite class="citation news cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20060324152626/http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx">"Looking at the WMF issue, how did it get there?"</a>. MSRC. Archived from <a rel="nofollow" class="external text" href="http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx">the original</a> on 2006-03-24. Retrieved 2018-10-27.</cite>

</li>

<li id="cite_note-4"><a href="#cite_ref-4">^</a> <cite id="CITEREFLitchfield" class="citation web cs1">Litchfield, David. <a rel="nofollow" class="external text" href="http://seclists.org/lists/bugtraq/2006/May/0039.html">"Bugtraq: Oracle, where are the patches???"</a>. seclists.org. Retrieved 2018-10-27.</cite>

</li>

<li id="cite_note-5"><a href="#cite_ref-5">^</a> <cite id="CITEREFAlexander" class="citation web cs1">Alexander, Kornbrust. <a rel="nofollow" class="external text" href="http://seclists.org/lists/bugtraq/2006/May/0045.html">"Bugtraq: RE: Oracle, where are the patches???"</a>. seclists.org. Retrieved 2018-10-27.</cite>

</li>

<li id="cite_note-6"><a href="#cite_ref-6">^</a> <cite id="CITEREFCerrudo" class="citation web cs1">Cerrudo, Cesar. <a rel="nofollow" class="external text" href="http://seclists.org/lists/bugtraq/2006/May/0083.html">"Bugtraq: Re: [Full-disclosure] RE: Oracle, where are the patches???"</a>. seclists.org. Retrieved 2018-10-27.</cite>

</li>

</ol></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards">CERT Secure Coding Standards</a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-07-30" href="https://en.wikipedia.org/wiki/?title=Defensive_programming&oldid=1303411493">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>